Following the trend, these are the bugs I squashed yesterday and today

• #377694 (graphviz), by backporting a lua test for the configure script.
• #377990 (libopengl-perl), by adding a build-dependency for libxi-dev.
• #377991 (freecraft), by applying a patch by Adriaan Peeters.

As the other day, the last bug was actually fixed twice (Bas Zoetekouw also prepared the NMU). The main problem here is that the BTS is being slow, and it's difficult to know that someone else has already fixed a bug.
So I guess that if you are going to join the the "fix one RC bug per day" movement, you'd better join #debian-bugs on oftc, and say which bug you are working on, so that we don't overlap that much.

So, last week was a bit bumpy since I was sick for a couple of days, and then had a power outage on Friday and Saturday, thus not being able to keep up with my daily RC bug fixing, but I've been catching up since then. I've uploaded patches done by Arjan Oosting, for packages that wouldn't compile with autoconf2.6: #379812 (kde-style-polyester), #379813 (kxmleditor) and #379815 (klog).

I uploaded a patch by Mart n Ferrari for lilo: #374477 (use MAKEDEV instead of mknod at postinst), and another patch by Mart n for courier-authlib #378571 (fixing the permissions of /var/run/courier/authdaemon).

I uploaded a patch by Andreas Jochens for ntlmaps: #379700 (fixing the build-dependency). A patch by Luca Bruno for predict: #379495 (fixing a change of location of forms.h). And a patch by Mike O'Connor for stardict: #379152 (fixing a misuse of size_t that made it fail in 64bit architectures).
Stardict had a problem with rpath that made me get to know the LIBTOOL_IS_A_FOOL hack, and I had to apply that, so that the binaries were not screwed up.

I also uploaded a fixed version of yacas, that included patches from Arjan Oosting (fixing #379261 and #379895) and Braun Gabor (fixing non-RC #295413). However, it's not like the only thing I've done is upload patches done by others. I've also done some patches myself:

• #379275, fixing fillets-ng's FTBFS.
• #379486, fixing a bashism in cbuild.
• #379200, changing PWD for CURDIR so that sudo works for building bluez-utils.
• #377781, fixing monotone so that it builds with the latest gcc, although it took a new upstream release for it to build in hppa.
• #378173, adding some checks for NULL, so that the new libsdl1.2-image does not make programs segfault
• #381248, dropping PAGE_SIZE in favour of sysconf(_SC_PAGESIZE) in libsdl1.2 so that it builds in powerpc

The amount of bugs currently affecting the next release is 247. It's not a secret that we are a bit behind the schedule (we should be at less than 200 bugs by now). But it's also totally possible to get back on track if we work together on fixing the current bugs and we stop uploading unneeded new releases that trigger new transitions.

On my last post, I stated that there were a number of RC bugs affecting etch, which was not completely accurate: I was counting only those affecting both etch and sid, this is to say those packages that are in etch and that still haven't been fixed on sid. It was pointed out to me that a number of packages (around 70 today) are waiting for perl to go into testing, so that they can go in too, and many of those fix RC bugs. In the end, a lot of RC bugs were not being marked as fixed in etch because of perl failing to build in hppa, mips and mipsel. After learning this, I decided that this perl bug needed to be fixed: I gathered a small team, including my guru friends, Dami n Viano and Mart n Ferrari, and between the three of us, we worked on fixing this nasty bug for three days. After a lot of time spent compiling an recompiling perl in an hppa box, we finally found out that the problem was due to a particular optimization flag (-fdelayed-branch) in gcc-4.1. Compiling the conflictive source file without that flag makes the bug go away. So, we submitted a patch and are now waiting happily for Perl's maintainer Brendan O'Dea to make the fixed upload. Hopefully, the number of RC bugs concerning etch will go down quite a lot during the next week, as the affected packages are able to migrate.

One new boot process hotspot was tested yesterday: using dash instead of bash. Got a good reduction of 3 seconds in the boot time. The results and method used are in the project webpage. Nevertheless, this was different from the 6 seconds obtained by Margarita Manterola in her slides from debconf6.
On the other side, with the aim of having a script for checking lintian rules and LSB compliance, I've started to take a look to the script written by Petter Reinholdtsen. It is written in perl so I took a quick tutorial of perl first :)

Debian sid was installed and the installation log can be found here. There is a link to a list of the packages installed with the distribution update from etch and the resulting init scripts. Besides, bootcharts and other resources will be available in this section.
Using the same sid installation, from the hotspots yesterday I tried to load the hwclock on the background with a 2 seconds reduction in the boot time. The bootcharts and scripts are availabe here as well.
Finally, depmod is not used any more in sid's module-init-tools and this is one of the hotspots. This was removed as a result from a discussion started by Margarita Manterola in debian-devel. Just by adding it again from an old script, the 2 second reduction from hwclock was lost.

Following my talk about Optimizing boot time (slides and the raw material now available), we had several discussions along DebConf6 as to how to make parallel booting a real option. So, Maxy decided to write a small C program called rcpar, that basically has the same functionality of the "shell" concurrency of /etc/init.d/rc, but since it's written in C, it's able to handle the output in a much cleaner way (and it will also handle interactive scripts in the near future). Darcs repository: http://maxy.com.ar/~maxy/darcs/rcpar I will probably be uploading an rcpar package to Debian experimental this weekend.

Debconf6 is finally over, and thanks to Maulkin's nice picture, I've got a new hackergotchi and decided to reactivate my blog that had to be taken down due to spam problems It's not a secret that I'm not really happy about how many things went in Debconf6, but I am happy of having spent those days with so many nice Debian people. It would be great if we could gather more frequently, just to hang out for a while (and maybe play one or two games of Mao). Anyway, I'm still recovering from almost two weeks of hard-core stress, trying to keep up with everything. I'm still lagging with much of the work that I had originally intended to do during Debconf, and my backlog keeps growing. Hopefully, I'll be able to clear things up soon.

This past couple of weeks saw a lot of Debian and Ubuntu work from me in (hopefully) equal measure. For Debian, I whipped up new versions of robotour, xshisen, libmemcache, and gtklp; robotour finally installs in /usr/games as it should be; xshisen acks NMUs and finally has a sane source package (well, a little bit tipsy still, but at least it’s now fixes the NMU source b0rkage;) libmemcache’s -dev now installs its headers to the right location; and gtklp bumps to a new upstream, with touch-fu replacing AM_MAINTAINER_MODE for seamless build. Thanks a lot to my wonderful sponsors Margarita Manterola, Sylvain Le Gall, and Andreas Metzler for the uploads! On the other hand, opendchub has migrated to testing, and its initscript failed (not to mention missing a manpage) I’ve fixed the latter, but I still have to figure out how to fix the former; I’ll probably have to consult the reference and add an unprivileged opendchub system user and configure the daemon to use that, or fix the source and allow flexible redefinition of opendchub’s working/configuration directories (currently hardcoded to $HOME/.opendchub). Either way, I have to touch the source and make patches; and I would appreciate it very much if my dearest readers can help out On the lighter (or heavier, depending on your POV) side, I noticed that Steve McIntyre posted an RFH for cvs, and I’ve decided to help out a bit. Seeing the source, I was pleasantly surprised as the age (and design) of this package, and it would be a blast for me to study this (and fix bugs, prepare patches, and release new versions while at it. It would also prepare me better for NM as well. As for my Ubuntu work, I’ve upgraded my Breezy Badger desktop to Dapper Drake last Monday (just in time for Flight 4,) and I’m quite amazed at the new features of this release. Like many folks I just loved xchat-gnome’s notification feature (especially when you’re moving in between workspaces very often) and was very much pleased with the speed of Gnome 2.13.91 (so much so that I’ve departed from my normal Ion3 desktop without regretting it. But of course, since Dapper Drake is the latest development branch, there were some snags that I got to encounter. One particular bug was with masqmail, because the 0.2.21-1ubuntu1 version created a /var/run/masqmail directory, but since /var/run is mounted as a tmpfs in Dapper, masqmail will complain the next time it restarts. Another (probably cosmetic) bug(?) was with tuxpaint, since it placed a couple of launchers in the Gnome Applications menu, one on Education and the other on Graphics. I’ve yet to see if tuxpaint’s is a genuine bug or just a design decision, but I’ve fixed masqmail’s, and 0.2.21-1ubuntu2 should be on Dapper now, thanks to Daniel Holbach. So far I’m loving the new Ubuntu release, and with FeatureFreeze finally here that means I’ll have to drag my desktop box again to the local internet cafe to do yet another aptitude dist-upgrade. Gaah, I need a laptop!

I just learned that Margarita Manterola became a Debian Developer recently. /me rejoices!

I just learned that Margarita Manterola became a Debian Developer recently. /me rejoices!